HAL FDCAN migration: List of applicable concepts

This section provides information about the HAL FDCAN applicable architecture concepts.

Concepts for FDCAN

Concept

Description

Separation of initialization and configuration functions

The initialization has been split into separate init and config functions:

  • HAL_FDCAN_Init():initializes the handle and links it to an FDCAN instance.

  • HAL_FDCAN_SetConfig(): Applies the global FDCAN configuration settings. After this, additional configuration functions should be called to set up bus-specific parameters such as filters, FIFOs, and other related settings.

Renaming of the handle structure

The handle structure has been renamed to hal_fdcan_handle_t.

Renaming unitary init structures

The init structure has been removed and moved into hal_fdcan_config_t configuration structure.

Remove MspInit and MspDeInit callbacks

hal_fdcan_MspInit() and hal_fdcan_MspDeInit() are no longer availableare no longer available and have been replaced by a user sequence to initialize and configure FDCAN .

Unitary configuration APIs

New APIs are available to get and set FDCAN features.

Introduction of HAL user data set/get APIs

Two functions to set and get user data are available: HAL_FDCAN_SetUserData() and HAL_FDCAN_GetUserData().

Individual callback registration APIs replace global register and unregister functions

The callback registration is handled by specific functions for each FDCAN event. These functions are used to register callback functions for different FDCAN events.

Removal of hardware-related macros in HAL2

All hardware macros have been removed from the HAL FDCAN driver, and equivalent services are ensured through the LL APIs.

Revised and optimized HAL state machine

The FDCAN is now managed by five states:

  • HAL_FDCAN_STATE_RESET

  • HAL_FDCAN_STATE_INIT

  • HAL_FDCAN_STATE_IDLE

  • HAL_FDCAN_STATE_ACTIVE

  • HAL_FDCAN_STATE_POWER_DOWN

Revised and optimized HAL API status returns

The HAL FDCAN functions were updated to return:

  • HAL_INVALID_PARAM: in case of a NULL p_config structure pointer.

  • HAL_ERROR: in case of an error.

  • HAL_TIMEOUT: in case of a user timeout.

  • HAL_BUSY: in case of an ongoing process.

  • HAL_OK: in case of a successfully completed operation.

Revised and optimized HAL error management

Redesign the error handling mechanisms within the HAL to enhance the detection, reporting, and management of errors.

Replaced TypeDef suffix with _t in type names

All TypeDef parts of the HAL FDCAN driver have been removed and replaced by _t.

Replaced nonmodifiable pointers with const keywords

Const keywords have been added to non-modifiable pointers to ensure that either the pointer itself or the data it points to cannot be modified. This enhances code safety and readability, prevents unintended modifications, and renders code more robust and maintainable.

Assertion implementation and usage in HAL1

The parameters and state are checked using ASSERT_DBG_STATE and ASSERT_DBG_PARAM macros.

Provide RTOS-compatible acquire/release bus services for communication peripheral drivers.

New functions, HAL_FDCAN_AcquireBus() and HAL_FDCAN_ReleaseBus(), are provided to allow the acquisition and release of a HAL FDCAN handle, protecting a full sequence.

Replace Finite Parameter Defines (Including PPP Instances) with Enum Types at HAL Levels.

Finite parameters (including FDCAN instances) have been converted into enumerated types (enums) at HAL level. This improves code readability, maintainability, and type safety.

Add HAL_PPP Prefix to All HAL Peripheral APIs (Defines, Macros, Types, and Functions).

All HAL FDCAN functions start with HAL_FDCAN.All HAL FDCAN enum and struct start with hal_fdcan.

Other HAL FDCAN changes

Concept

Consideration

Rework the FDCAN Rx, Tx, and Tx Event headers using union-based bitfield structures for clearer and simplified access.

Simplify header read/write operations by using unions to overlay raw 64-bit data with structured bitfields, enabling efficient access to individual header elements while maintaining alignment with hardware descriptors.

Rework the interrupt activation/deactivation APIs to harmonize interrupt management by enabling or disabling individual interrupt lines through a unified interface.

Modify existing interrupt activation functions by splitting the HAL1 API into two separate APIs: one dedicated to individual interrupt source enabling, and another for enabling entire interrupt lines.

Add an API to recover from Bus-Off error by simplifying the recovery process into a single function call.

Provide HAL_FDCAN_Recover() API callable from the application or error callback, which asserts the peripheral is in ACTIVE state and handles recovery internally.

Rework CCU management

Rework the calibration sequence to avoid hardware conflicts when multiple FDCAN instances access the shared Clock Calibration Unit (CCU).

Provide to the user the capacity to calculate bit timing through a utility.

The files stm32_utils_fdcan.c and stm32_utils_fdcan.h are provided with services that allow calculation of the FDCAN bit timing.

TTCAN is no longer supported.

All TTCAN-related constants, macros, types, and functions have been removed and are not supported in HAL2.